あらゆる重要なソフトウェア開発の取り組みには、分析、ユーザーエクスペリエンスデザイン、開発、テストなど、いくつかの異なる活動が必要です。活動指向チームはこれらの活動を中心に組織され、ユーザーエクスペリエンスデザイン、開発、テストなどに専任のチームがいます。活動指向は多くの利点を約束しますが、ソフトウェア開発は通常、成果指向チームで行う方が良いでしょう。

エイリアシングは、同じメモリ位置に複数の参照からアクセスするときに発生します。多くの場合、これは良いことですが、予期しない方法で発生することが多く、混乱を招くバグにつながります。

これは、かなり長い間存在しているアンチパターンの1つですが、現時点では特に流行しているようです。私はこれについてEric Evansと話していましたが、私たち二人は、それらがより一般的になっているように見えることに気づきました。適切なドメインモデルを大きく推進するものとして、これは良いことではありません。

Andrew Koenigは、JOOPの記事で「アンチパターン」という用語を初めて作り出しましたが、残念ながらインターネットでは入手できません。本質的な考えは（私が覚えている限り）、アンチパターンは、最初は良いアイデアのように思えるが、トラブルに巻き込まれるものだということです。それ以来、この用語は単に悪いアイデアを示すために使用されることがよくありますが、元の焦点の方が有用だと思います。

これは友人の友だちからの話です。少なくともどこかでは真実でなければならないと確信しています。

バイモーダルITとは、ソフトウェアシステムを管理と制御のためにこれら2つの異なるカテゴリに分割するという誤った概念です。

• フロントオフィスシステム（エンゲージメントシステム）は、迅速な機能開発のために最適化されるべきです。これらのエンゲージメントシステムは、変化する顧客のニーズとビジネスチャンスに迅速に対応する必要があります。この迅速な開発サイクルに必要なコストとして、欠陥は許容されるべきです。
• バックオフィスシステム（記録システム）は、信頼性のために最適化されるべきです。記録システムとして、企業に損害を与える欠陥がないことが重要です。その結果、変更の速度が低下します。

スーパークラスの呼び出しは、オブジェクト指向フレームワークで時々発生するマイナーなにおい（または、好きな場合はアンチパターン）です。その症状は非常に見つけやすいです。何らかのフレームワークに接続するために、スーパークラスから継承しています。ドキュメントには、「自分のやりたいことをするには、processメソッドをサブクラス化するだけです。ただし、メソッドをスーパークラスの呼び出しで開始することを忘れないでください」のようなことが書かれています。例としては、次のようなものがあります。

最新のアプリケーションサーバーでよく宣伝されている機能の1つは、クラスターでのフェイルオーバーを提供することです。クラスタリングはアプリケーションの信頼性を向上させます。サーバーの1つがダウンした場合、顧客にサービスを提供するためのサーバーがさらにいくつかあります。フェイルオーバーはさらに信頼性を高めることができます。インタラクションの途中でサーバーがダウンした場合、クラスターはそのインタラクションを別のサーバーに移動できます。

ただし、これは問題になる可能性があります。

2つまたは3つの値が一緒に収集される場合は常に、それらを$％^＆*オブジェクトに変換します。

--私（声の方が面白かった）

これは、リファクタリングブックのお気に入りのコードのにおいの1つです。同じ少数のデータ項目が常に一緒に渡されているのを見ると、それに気づきます。開始と終了は、範囲になろうとしているデータの塊の良い例です。多くの場合、データの塊は、誰もオブジェクトに変換することを考えないプリミティブ値です。

（これはあなたの辞書への追加です。）

テストできない（形容詞）：テストできないソフトウェア。

それに慣れるのは簡単ですが、ソフトウェア開発の世界には多様性に関する深刻な問題があることは明らかです。これは、人口全体と比較して、人々の割合に顕著な違いがあることを意味します。最も明白な違いの1つは女性の割合が低いことであり、これは世界中で当てはまります（ただし、中国では著しく少ないです）。私が多くの時間を過ごしている米国では、アフリカ系アメリカ人の不足も明らかです。なぜこのような不均衡が存在するのか、そしてそれについて何ができるのかについては、多くのことが書かれています。しかし、ここでは、より根本的な質問、つまり、それが重要かどうか、に焦点を当てたいと思います。

先日、本のサンプルコードをいじっていました。いくつかの変更を加え、すべてを動作させ、テストを実行し、それを個人のリポジトリにコミットしました。その後、別の領域に移動して、いくつかの変更を加えました。そして、前の領域で予期しないテストが壊れました。自動テストを実行するポイントの1つは予期しない中断を見つけることですが、このブックコードは完全に独立した領域にあります。これは奇妙でした。

アジャイルメソッドの一般的な、おそらく支配的なプラクティスは、構築されているソフトウェアの機能のリスト（多くの場合、ストーリーと呼ばれます）を開発することです。これらの機能は、インデックスカード、作業キュー、バーンダウンチャート、バックログ、または選択したツールを使用して追跡されます。

最近、かなりの数のプロジェクトで耳にした混乱があります。それは次のように機能します

• 彼らはアジャイルプロセスを使用したいと考えており、スクラムを選択します
• 彼らはスクラムのプラクティス、そしておそらく原則さえも採用しています
• しばらくすると、コードベースがめちゃくちゃになっているため、進行が遅くなります

フラグ引数は、その値に応じて異なる操作を実行するように関数に指示する一種の関数引数です。コンサートの予約をしたいとしましょう。これを行うには、通常とプレミアムの2つの方法があります。ここでフラグ引数を使用するには、次のようなメソッド宣言になります

時々、いくつかのデータを扱うとき、そのデータは私が期待するよりも正確です。精度が良いので、もっと多い方が良いと思うかもしれません。しかし、隠れた精度は、いくつかの微妙なバグにつながる可能性があります。

仲間のThoughtBloggersに注目しているなら、私のファウルボットの1つがヒューズを飛ばしたように見えることがわかるでしょう。オーストラリアの太陽は明らかにこれらのスウェーデンモデルを焦がします。

Jonはデータ転送オブジェクトに悩まされていますが、DTOが悪いわけではありません。他のパターンと同様に、特定のコンテキストで役立ちます。パターンには常に2つの部分があります。方法と時です。それらを実装する方法を知る必要があるだけでなく、いつそれらを使用するか、そしていつそれらをそのままにするかを知る必要もあります。

最近JavaScriptをいじっていますが、ゲッターとセッターに同じ関数名を使用するという習慣が印象的です。そのため、jQueryでバナーの高さを調べたい場合は、$("#banner").height()を使用し、高さを変更したい場合は、$("#banner").height(100)を使用します。

この規則は、Smalltalkで使用されていたため、私にはなじみがあります。banner heightで値を取得し、banner height: 100で値を変更できます。それがsmalltalkの規則であることを知っているだけで、私がそれを好きになることが期待できます。なぜなら、私はその言語に遠いながらも永続的な愛情を持っているからです。しかし、最高の物でさえ欠陥があり、このコーディングスタイルに対する嫌悪感を隠すことはできません。

IT部門でよくある質問は、カスタムソフトウェアを構築するか、パッケージを購入することで機能を提供するかどうかです。私がプログラミングをしているよりも長い間、その選択をする方法について議論が続いてきました。これに関する私の基本的な立場は、ユーティリティと戦略の二分法に基づいています。要約すると、これは、サポートしているビジネスプロセスが競争上の優位性の一部である場合はカスタムソフトウェアを構築する必要があり、そうでない場合はパッケージを購入してビジネスプロセスをパッケージの動作に合わせて調整する必要があることを意味します。

私の意見の明らかな卓越性にもかかわらず、多くの企業はこれを行っているようには見えません。多くの場合、彼らは二分法を無視します。これは1つの問題です。しかし、ここで焦点を当てたい問題は、パッケージを購入する際のよくある罠です。

ソフトウェアの良い点の1つは、人々がそれを望んでいて、すぐにそれを望んでいるように見えることです。組織がチームにソフトウェアの生産をスピードアップするように求めるのは普通のことです。そして、時々、組織は本当にコミットメントを示す方法で支援しようとします。チームに人を増やすためにお金を使うことによってです。

私の同僚や私がフィーチャーブランチについて話すのを聞いたことがある人は、私たちがこのパターンをあまり好まないことを知っています。私たちの反対意見の重要な部分は、ブランチの作成は簡単だが、マージは難しいという観察です。時々耳にする議論は、現代のバージョン管理ツールはマージを十分に容易にするため、フィーチャーブランチは価値があるというものです。

私は、ソフトウェア開発で見られるものを説明するために新語を作成する習慣があります。ソフトウェア開発にはまだ有用な専門用語が不足しているため、この分野のライターの間ではよくある習慣です。専門用語を構築する際の問題の1つは、専門用語が意味を失いやすいことで、意味的拡散のプロセスにあります - これは、私たちの専門用語に追加される可能性のあるもう1つの用語です。

スライドゥメントとは、スライドデッキとドキュメントの組み合わせです。これは、プレゼンテーション中のスライドと、後で読んでもらうための配布資料の両方として、単一のスライドデッキを使用できるという考え方です。問題は、これら2つのニーズによってスライドに求められるものが大きく異なるため、両方を満たすことができないことです。その結果、スライドゥメントは通常、両方で失敗します。

本番サーバーを稼働させ続けるのは、面倒な作業になる可能性があります。オペレーティングシステムとその他の依存ソフトウェアに適切なパッチを適用して、最新の状態に保つ必要があります。ホストされているアプリケーションは定期的にアップグレードする必要があります。効率的に実行され、他のシステムと適切に通信するように環境を調整するために、構成の変更が定期的に必要になります。これには、コマンドラインの呼び出し、GUI画面間のジャンプ、テキストファイルの編集などを組み合わせる必要があります。

その結果、ユニークな雪の結晶（スノーフレーク）が生まれます。スキーリゾートには適していますが、データセンターには適していません。

ストーリーテストとは、ユーザーストーリーの一部として提供されるソフトウェアを記述および検証するために使用されるビジネス向けテストです。ストーリーが詳細化されると、チームはストーリーの受け入れ基準となるいくつかのストーリーテストを作成します。ストーリーテストは、ソフトウェアの回帰スイートにまとめることができ、要件（ユーザーストーリー）からテスト、そして（実行を通じて）システムの動作までをトレーサブルにします。ストーリーテストは通常、広範なスタックテストです。

これは残念ながら一般的なアーキテクチャスタイルだと思います。あなたの会社は非常に高価なインフラストラクチャソフトウェアを購入します。その後、プロジェクトに適していなくても、余分な労力がかかっても、プロジェクトでそれを使用するように指示されます。せっかくお金を払ったのに、無駄にしたくないでしょう？

私のキャリアがフルタイムの執筆活動に移行するにつれて、日々のソフトウェア開発の現実から距離を置くことについてよく心配しています。他の著名人が現実との接触を失っていくのを見てきました。そして、私も同じ運命をたどるのではないかと恐れています。これに対する私の最大の抵抗源はThoughtworksです。Thoughtworksは、私の足を地につけたままにしておくための定期的な現実の投与として機能しています。

Thoughtworksはまた、現場からのアイデアの源としても機能しており、同僚が発見し、開発した役に立つことについて書くことを楽しんでいます。通常、これらは有益なアイデアであり、読者の一部が使用できることを願っています。今日の私のトピックは、それほど楽しいトピックではありません。これは問題であり、私たちには答えがない問題です。

ソフトウェアの世界では、「ウォーターフォール」は、反復型またはアジャイル型の考え方とは対照的なソフトウェアプロセスのスタイルを説明するためによく使用されます。ソフトウェアの多くのよく知られた用語と同様に、その意味は明確に定義されておらず、起源は不明瞭です。しかし、私はその本質的なテーマは、大きな労力を活動に基づいて段階的に分割することだと考えています。